On-device multiplexing of streaming media content

ABSTRACT

Techniques are disclosed for multiplexing a dynamic bit-rate video stream with an audio stream received by a client device in a manner that allows the resulting multiplexed stream to be played back without disruption, despite dynamic changes in the bit rate of the video stream that may occur. A content server may stream both a video stream and an audio stream to a client device for playback. The client device may multiplex the video and audio streams prior to them being presented to a playback engine for decoding and playback to a user.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of the co-pending U.S. patentapplication titled, “ON-DEVICE MULTIPLEXING OF STREAMING MEDIA CONTENT,”filed on Apr. 13, 2015 and having Ser. No. 14/685,558, which is acontinuation of the U.S. patent application titled, “ON-DEVICEMULTIPLEXING OF STREAMING MEDIA CONTENT,” filed on Dec. 18, 2009 andhaving Ser. No. 12/642,567, Now U.S. Pat. No. 9,009,337, Issued Apr. 14,2015, which claims priority to the U.S. provisional patent applicationtitled “SEAMLESS BIT RATE STREAM SWITCHING,” filed on Dec. 22, 2008 andhaving Ser. No. 61/140,032, and which also claims priority to the U.S.provisional patent application titled “SEAMLESS BIT RATE STREAMSWITCHING,” filed on Mar. 27, 2009 and having Ser. No. 61/164,327. Eachof these related applications is hereby incorporated herein in itsentirety.

BACKGROUND OF THE INVENTION Field of the Invention

Embodiments of the invention generally relate to the playback of audioand video data streamed over a computer network to a client device. Morespecifically, embodiments of the present invention relate tomultiplexing dynamic bit-rate video and audio video streams on a clientdevice.

Description of the Related Art

Consumer demand for digital video products has greatly increased inrecent years. Examples of popular applications include videoconferencing, video security and surveillance and, importantly, thedistribution of entertainment content, including a rapidly a growingmarket for Internet video streaming. Video encoding and compression is acommon component of these applications. Coding-decoding (codec)algorithms allow digital video and audio data to be transmitted in realtime. Several codecs currently in use have been developed as an industrystandard such as MPEG-2, MPEG-4, H.264/AVC and AVS, while others areproprietary algorithms, such as On2, Real Video, and Windows Media Video(WMV) (now standardized by SMPTE as VC-1).

Internet video streaming of compressed audio and video is typicallyperformed using a network of computing systems collectively referred toas a digital content distribution system. And such systems typicallyinclude a content server, a content player, and a communications networkconnecting the content server to the content player. The content serverstores digital content files available for download from the contentserver to the content player. The digital content files correspond tomovies, televisions shows, sporting events, music productions, etc. Thedigital content file typically provides sequential content data,organized according to playback chronology, including audio data and/orvideo data.

The content player (e.g., a Blu-Ray® disk player) downloads and plays adigital content file, usually in response to a user request. The processof playing the digital content file includes decoding and renderingaudio and video data to generate audio and video signals sent tospeakers and a display screen. In practice, the content server transmits(i.e., streams) digital content to the content player, which plays thedigital content file while content data is being received. To accountfor variable latency and bandwidth within the communications network, acontent buffer queues incoming content data ahead of the content dataactually being played. During periods of network congestion, which leadsto lower available bandwidth, less content data is added to the contentbuffer, which may drain down as content data is being de-queued tosupport playback at a certain playback bit rate. However, during periodsof high network bandwidth, the content buffer is replenished andadditional buffer time is added until the content buffer is generallyfull again. In particular systems, the content buffer may queue contentdata corresponding to a time span ranging from seconds to more than aminute.

SUMMARY OF THE INVENTION

One embodiment of the present invention includes a method for encoding amedia file to allow on-device multiplexing of audio and video data anddynamic bit rate switching. The method may include providing a pluralityof video encodings of the media file. Each video encoding may provide anencoding of the media file at a distinct video bit rate and each videoencoding may include a plurality of portions of video data. In each ofthe plurality of portions of video data, one or more insertion pointsfor multiplexing portions of video data with portions of audio data onthe client device is identified. Additionally, one or more of theportions of video data may be padded to be aligned to a continuity countboundary. The method may also include storing, in the video encoding, afile header which includes an indication of the positions of theplurality of insertion points in the video encoding and providing atleast one audio encoding of the media file. The audio encoding mayinclude a header indicating a plurality of audio segments, eachcorresponding to one of the plurality of portions of video data. Themethod may also include storing the plurality of video encodings and theaudio encoding on a media delivery system in order to be streamed toclient device upon request.

In a particular embodiment, each of the plurality of video encodingsincludes a sequence of one or more groups of pictures (GOPs). Forexample, each GOP may be encapsulated in a sequence MPEG-2 transportstream packets. In such a case, padding at least one portion of videodata to be aligned to a continuity count boundary may comprise addingvideo filler packets such that each GOP begins with an MPEG-packethaving a continuity count of 0 and ends with a packet having acontinuity count of 15.

In a particular embodiment, the method may further include receiving,from a client device, a request to stream the media file, transmitting,to the client device, the file header generated for each of theplurality of video encodings and the file header generated for the audioencoding. In response to requests from the client device, portions ofvideo data from at least one of the video encodings and audio segmentsform the audio encoding may be streamed to the client device. Further,the client device may be configured to multiplex the streamed portionsof video data with the streamed portions of audio segments to generate amultiplexed stream presented to a playback engine on the client devicefor decoding and playback. The client device may be further configuredto switch streaming portions of video data from a first one of the videoencodings to a second one of the video encodings.

Another embodiment of the invention includes a computer-implementedmethod for multiplexing an audio stream and a video stream on a clientdevice. The method may generally include transmitting, to a streamingmedia server, a request to stream a media file stored on the streamingmedia server. The method may also include receiving, from the streamingmedia server, a file header describing each of a plurality of videoencodings of the media file available from the streaming media server,and receiving, from the streaming media server, a file header describingat least one audio encodings of the media file available from thestreaming media server. The method may also include transmitting, to thestreaming media server, a request to download at first portion of videodata from a first one of the plurality of video encodings and at least afirst portion of audio data from the audio encoding, receiving therequested first portion of video data and first portion of audio data,and multiplexing the first portion of video data and first portion ofaudio to generate a multiplexed stream for playback by a playback engineon the client device.

In a particular embodiment, this method may also include transmitting,to the streaming media server, a second request to download at secondportion of video data from a second one of the plurality of videoencodings and at least a second portion of audio data from the audioencoding. And in response, receiving the requested second portion ofvideo data and second portion of audio data. This method may alsoinclude multiplexing the second portion of video data and second portionof audio for playback by the playback engine on the client device andadding the multiplexed second portion of video data and second portionof audio to the multiplexed stream. The playback engine is generallyconfigured to decode and playback the multiplexed stream withoutdisrupting playback when decoding and playing back the first and secondportions of video data.

Other embodiments include, without limitation, a computer-readablemedium that includes instructions that enable a processing unit toimplement one or more aspects of the disclosed methods as well as asystem configured to implement one or more aspects of the disclosedmethods.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features of the presentinvention may be understood in detail, a more particular description ofthe invention, briefly summarized above, may be had by reference toembodiments, some of which are illustrated in the appended drawings. Itis to be noted, however, that the appended drawings illustrate onlytypical embodiments of this invention and are therefore not to beconsidered limiting of its scope, for the invention may admit to otherequally effective embodiments.

FIG. 1 illustrates bit rate switching and on-device multiplexing in aBlu-Ray® disc player, according to the specification published by theBlu-Ray Disc Association.

FIG. 2 illustrates an example networked computing environment whichincludes a media delivery system streaming content to a networked clientdevice, according to one embodiment of the invention.

FIG. 3 further illustrates the media delivery system of FIG. 2,according to one embodiment of the invention.

FIG. 4 further illustrates the content player of FIG. 2, according toone embodiment of the invention.

FIG. 5 illustrates a method for encoding a media file to allow foron-device multiplexing on a networked client device, according to oneembodiment of the invention.

FIG. 6 illustrates a method for on-device multiplexing of streamingmedia content delivered to a networked client device, according to oneembodiment of the invention.

FIG. 7 illustrates an example of multiplexing a video and audio streamsupplied to a playback engine, according to one embodiment of theinvention.

FIG. 8 further illustrates portions of audio and video encoded in audioand video streams prior to being multiplexed on a client device,according to one embodiment of the invention.

DETAILED DESCRIPTION

Embodiments of the invention provide techniques for decoding and playingmedia content streamed over a communications network to a networkedclient device, such as a set-top box, PC, mobile telephone, video gamingplatform, or Blu-Ray® disc player. More specifically, embodiments of theinvention provide for multiplexing a dynamic bit-rate video stream withan audio stream received by a client device in a manner that allows theresulting multiplexed stream to be played back without disruption,despite dynamic changes in the bit rate of the video stream that mayoccur.

In practice, a digital content file (e.g., a movie title) stored on acontent server may be encoded using a variety of different bit rates.Prior to initiating playback, the content player may measure availablebandwidth from the content server and select a digital content filehaving a bit rate that can be supported by the measured availablebandwidth. To maximize playback quality, the content player may selectto stream the digital content file with the highest bit rate that doesnot exceed the measured bandwidth. However, the amount of bandwidthavailable may change during playback of AV programs downloaded over adata network. Thus, it becomes desirable to seamlessly switch betweenvideo streams of varying bit rates, e.g., to reduce the streaming bitrate when prevailing network bandwidth deteriorates. Seamless bit ratestream switching during playback balances a viewer's desire for a highquality viewing experience and efficient use of the available networkbandwidth of the network connection over which AV programs aredownloaded. For example, the first few seconds of a program sent over anetwork to a digital media player after the viewer initiates playbackmay be digitally encoded at a low bit rate so as to reduce thetransmission time of program content over the network and hence minimizethe delay between initiating playback and presenting content to theviewer. Thereafter, as playback continues, the bit rate of encodedcontent sent to the digital media player may be increased to takeadvantage of available network bandwidth and to present the highestquality audiovisual content to the viewer.

However, certain prevalent techniques for switching bit rates in somedigital media players are awkward and significantly degrade a viewer'sviewing experience. For example, the Blu-Ray® Disc Association (BDA), anindustry consortium responsible for establishing format standards forBlu-Ray® disc technology, has established standards known collectivelyas the “Blu-Ray® Disc Format Specifications” that include the “Blu-Ray®Disc Read-Only Memory (ROM) Format,” the “Blu-Ray® Disc recordableFormat,” and the “Blu-Ray® Disc Rewritable Format.” For ease ofreference, these specifications are referred to herein as a collectionas the “Blu-Ray® specification.”

The Blu-Ray® specification includes specifications for a Blu-Ray® DiscPlayer (BD-Player) to playback digitally encoded AV programs downloadedover a data network such as the Internet. According to the Blu-Ray®specification, portions of an AV program downloaded to a BD-Player maybe stored in a local storage as one or more AV stream files subsequentlydelivered to the decoder of the BD-Player as a stream of AV data forplayback. Effectively, the downloaded AV program is presented to thedecoder as a virtual Blu-Ray® disc. However, the Blu-Ray® specificationrequires configuring the decoder of the BD-Player with a size and a timelength of all portions of an AV program contained in the AV stream filesbefore playback of the AV program can begin. Thus, switching bit ratesduring playback of an AV program requires that the decoder of theBD-Player be reconfigured because the size or number of portions of theAV program typically changes when the bit rate is switched. Otherprotocols for streaming AV content over data networks may have similarrequirements for configuring size or length of portions of an AV programprior to content streaming and playback. Reconfiguring the decoderduring playback is a suboptimal solution for changing video (or audio)bit rates because doing so noticeably disrupts an otherwise smoothpresentation of audio and video.

In one embodiment, a content server may stream both a video stream andan audio stream to a client device for playback. The client device maymultiplex the video and audio streams prior to them being presented to aplayback engine. Further, as noted above, the bit rate of the videostream may change during playback in response to changes in prevailingbandwidth conditions. However, as also noted above, some devices havecertain constraints regarding how digital media is presented to aplayback engine for decoding and presentation to a viewer. For example,a playback engine on a Blu-Ray® disc player may require a multiplexedand encrypted data stream, where both a size and a length of eachportion of an AV program data is specified before playback of the AVprogram can begin.

Accordingly, in one embodiment, a stream formatter or other playbacklogic on the client device may be configured to present such a playbackengine with a multiplexed video stream that satisfies these constraints.As described in greater detail herein, the available video stream filesfor a given title may be encoded in a manner to support on-devicemultiplexing with dynamic bit rate switching. For example, each fileencoding a video or audio stream may include a header specifying theportions (and sizes) of AV data is contained in a given audio or videofile. In one embodiment, the stream formatter may be configured toretrieve this information regarding each available video (and audio)stream file available for a given title prior to initiating playback.And the stream formatter may use this information to build an index ofthe stream used to configure the playback engine as well as to multiplexthe audio and video streams. For example, the playback engine may beconfigured with a size for each portion of the video data specified asthe largest size of that portion stored in any of the any of theavailable bit rate encodings. If a portion is then played back using alower-bit rate, the stream formatter may pad that portion as needed soas to match the size specified when the playback engine was configured.

The header generated for a given video stream may include a fieldindicating the size of the header, a field indicating byte (or packet)offset where the header ends and stream data begins, and an indexlisting insertion points in each group of pictures (GOP) where a segmentof audio may be multiplexed with the video to provide a multiplexed AVstream for a playback engine on a client device.

Further, during playback, the stream formatter may change the bit rateat which video is being decoded and played back by changing which videofile is being streamed from the content server, multiplexed with anaudio file, and supplied to the playback engine for decoding andplayback, without also requiring the playback engine to be reconfiguredwith each bit rate change and without causing other disruptions toplayback of the streaming media content. That is, the formatter may varythe bit rate of the video in an encrypted stream while still presentingit to the playback engine as a single multiplexed stream.

In one embodiment, each bit rate encoding of a media file includes aplurality of GOPs and each GOP may be stored in a variable number oftransport stream packets (e.g., MPEG-2 M2TS packets), depending on thebyte size of the GOP itself Note, the MPEG-2 standard specifies a fixedpacket size of 188 bytes in length. However, additional fields may beadded by other standards. For example, the Blu-Ray® specification addsfour bytes of additional data to each 188 byte MPEG-2 packet, resultingin a packet size of 192 bytes). By configuring each GOP to begin on anI-frame boundary (a frame which contains all necessary renderinginformation within itself, and includes a sequence header at the startof each GOP), the bit rate (and video data supplied to the playbackengine) may be changed at any GOP boundary without disrupting videoplayback (save for an increase or decrease in video quality resultingform the change in bit-rate). To preserve a playback continuity countincluded in the header of each MPEG-2 transport stream packet, each GOPmay be padded with video filler packets so as to end with a continuitycount of 15, resulting in each successive GOP to begin with a packethaving a continuity count of 0 (assuming a four-bit continuity counteris used, as is the case for the MPEG-2 transport stream standard). Thisallows the bit rate to be switched at any GOP boundary without resultingin a continuity count error.

Note however, although a particular embodiment of the invention isdescribed using a BD-Player which implements the Blu-Ray® specificationsas an example of a client device, it should be understood thatembodiments of the invention may be adapted to for a broad variety ofstreaming media protocols. Accordingly, references to the Blu-Ray®specifications or a BD-Player are made as an illustrative example andnot intended to be limiting of the present invention. Further, in thefollowing description, numerous specific details are set forth toprovide a more thorough understanding of the present invention. However,it will be apparent to one of skill in the art that the presentinvention may be practiced without one or more of these specificdetails. In other instances, well-known features have not been describedin order to avoid obscuring the present invention.

FIG. 1 illustrates bit rate switching and on-device multiplexing in aBlu-Ray® disc player, according to the specification published by theBlu-Ray Disc Association. As shown, a HyperText Transfer Protocol (HTTP)server 101 is coupled to a Blu-ray Disc Player 102 via a datacommunications network, such as the Internet. In the example, server 101stores multiple video files 103 and an audio file 113, eachcorresponding to a given media property (e.g., a movie). In thisexample, video files 103 encode the given media property in threedifferent bit rates: 500 kbps, 1000 kbps, and 1500 kbps. Additionally,the audio file 113 encodes an audio stream associated with the mediaproperty at 128 kpbs. Each video file 103 includes a header having aplaylist information file 105, segments of video (e.g., MPEG-2 transportstream packets of storing video data corresponding to 2 seconds of videoat a progressive frame rate of 30 fps), and one or more clip informationfiles. Each clip information file corresponds to one of the segments ofvideo data. For example, the file 103 stored at 1000 kbps includes aplaylist information file 105, clip information files 107 a-n, andcorresponding video stream files 109 a-n.

Each AV stream file has a corresponding clip information file thatstores time stamps of the access points into the corresponding AV streamfile that are referenced in the playlist information file. Duringplayback of an AV program, and in particular, during playback of aportion of the AV program that corresponds to a playing interval definedin the playlist information file, the BD-Player reads the clipinformation file to find out the position where it should begin to readdata from the AV stream file corresponding to the playing interval.Further, the clip information files include information indicating wheresegments of audio from audio file 113 may be multiplexed with segmentsof video. For example, assume each video stream file 109 a-n storesapproximately 2 seconds of video, and each corresponding segment ofaudio stores approximately 2 seconds of audio. In such case, the clipinformation files 107 a-n may indicate a byte (or packet) offsetindicting a first and second point for each video stream file 109 a-n atwhich to insert a portion of the corresponding audio file 115 a-n,resulting in a multiplexed stream with alternating segments of audio andvideo data every two-thirds of a second. Of course, the size andplayback length of segments of audio and video data may be tailored tosuit the needs of a particular case. Nevertheless, as the Blu-Ray®specification allows for a maximum separation between video and audiodata of up to 1 second, using a video and audio segment size ofapproximately 2 seconds and a multiplexed stream alternating betweenaudio and video every two-third seconds has proven to be effective.

As shown, BD-Player 102 includes playback logic 104 and local storage106. The Blu-ray specification standard provides specifications forplayback logic 104 to download and write files to local storage 106including playlist information files, clip information files, andmultiplexed audio visual stream files. In effect, the Blu-rayspecification standard allows playback logic 104 to use local storage106 to create a virtual Blu-ray Disc that includes AV program contentdownloaded from a server over a network. To create such a virtualBlu-ray Disc using local storage 106, playback logic 104 must storeplaylist information files, clip information files, and AV stream filesin accordance with the Blu-Ray® specification.

In particular, according to the Blu-ray specification, playback of an AVprogram (e.g., AV program 103) cannot start until the correspondingplaylist information file (e.g., playlist information file 105), allcorresponding clip information files (e.g., clip information files 107a-n), and at least one AV stream file (i.e., an audio visual streammultiplexed from one of the video files 103 and the audio file 113) iscompletely downloaded to local storage 106. Once these files are presentin local storage 106, playback logic 104 can cause BD-Player 102 tobegin playback of the AV stream multiplexed from video file 103 andaudio file 113. After playback starts, playback logic 104 can continueto cause BD-Player 102 to download the remaining video files (e.g.,video files 109 b-n) and audio files (e.g., audio files 115 b-n) formultiplexing. So long as the next stream file needed at BD-Player 102 iscompletely downloaded to local storage 106 and multiplexed by playbacklogic 104 before the BD-Player has finished playing the current AVstream file, playback of an AV program will be presented to the viewerwithout any momentary stops or flickers or other playback events thatcause a noticeable interruption of smooth audio and video playback.

However, as discussed above, it may be desirable to switch bit ratesduring playback of a video program. For example, if BD-Player 102 isconnected to HTTP server 101 through a typical home Digital SubscriberLine (DSL) or cable modem which can download data at approximately 1500kbps, concurrent usage of the home DSL or cable modem, for example, byanother family member, can cause BD-Player 102 to fall behind indownloading AV stream files from server 101. That is, BD-Player 102 canno longer download AV stream files from server 101 as fast as the rateat which the AV stream files are being streamed to the decoder of theBD-Player. In such a case, it would be useful to be able to seamlesslyswitch, for example, from playing AV stream files at 1500 kbps toplaying AV stream files at 1000 kbps.

Unfortunately, to switch bit rates according to the Blu-rayspecification, the playlist information file, all the clip informationfiles, and at least one AV stream file for the new bit rate must becompletely downloaded to local storage 106 before playback of the AVprogram at the new bit rate can begin. For example, to switch fromplayback of AV program 103 at 1500 kbps to playback of AV program 103 at1000 kbps, playlist information file 105, clip information files 107a-n, and at least one video files 109 a-n must be completely downloadedto local storage 106 before BD-Player 102 can switch to playback of AVprogram 103 at 1000 kbps If the streaming bit rate were switched duringplayback of AV program 103 encoded at 1500 kbps, visible interruptionsmay occur as switching to a different playlist information file is notseamless for media processed according to the Blu-Ray® specification.Instead, switching to a different playlist information file results in avisible interruption in viewing a program that may last several seconds,causing a poor user experience.

In one embodiment, a BD-Player may be configured with additionalplayback logic to allow for seamless bit rate switching during playback,without requiring the BD-Player to be reconfigured with changed sizedata and without causing a noticeable interruption of smooth audio andvideo playback. In particular, as video files are downloaded forplayback, the size of the video file (or the size of groups of pictures(GOPs) in the clip file) is compared with a clip information file. Theclip information file may be used to configure the BD-Player prior toinitiating playback of streaming AV data. The playback logic 105 may padthe video file (or one or more GOPs in the clip file) such that the sizeof the clip file matches the configured size specified in the clipinformation file. Once padded, the video file 103 may be multiplexedwith the corresponding audio clip 115 a-n and presented to the decoderof the BD-player 102. Note, as shown, clips 115 a-n from a single audiofile 113 are multiplexed with any of the video files 103 as the videobit rate is switched as appropriate using the techniques describedherein. However, in an alternative embodiment, the audio data may alsoinclude multiple files, each encoded at different bit rates. In such acase, the playback logic 104 may also switch between audio bit rates asappropriate for prevailing bandwidth conditions.

FIG. 2 illustrates an example networked computing environment whichincludes a media delivery system 210 streaming content to a networkedclient device, according to one embodiment of the invention. As shown,FIG. 2 illustrates a media delivery system 210, media selection service214, viewing location 228, and ordering location 234. In one embodiment,a media server 201 of the media delivery system 210, presentation server216 of media selection service 214, BD-Player 202 of the viewinglocation 228, and computer 236 of the ordering location 234 are allconnected to data network 226. The data network 226 is included to berepresentative of any combination of computer networks capable ofdelivering data from one computer to another. For example, data network226 may comprise any combination of a local area network (“LAN”), a widearea network (“WAN”), the Internet, a telecommunications network, asatellite network, a cable television network, or a wireless network.Further, data network 226 may itself include one or more networkscoupled together to form a single logical network and that supportsappropriate network protocols (e.g., TCP/IP for the Internet).

Illustratively, media delivery system 210 includes a media library 212that comprises AV files 203. The term “audiovisual program” or “AVprogram” as used herein refers broadly to a collection of audio streamfiles, video stream files, or multiplexed audiovisual files that can bedelivered using a streaming media protocol over a data network. Examplesof AV programs include music, recordings of spoken words, movies, sportsprograms, television series episodes, documentary motion pictures,instructional programs, or any other form of program. AV files 203include a stored set of files that can be delivered on demand over anetwork connection to a computer such as BD-Player 202. In a practicalembodiment, there may be thousands of AV programs stored in or managedby the media delivery system 210. AV files 203 may include multiplevideo (and/or audio) encodings of a given title, where each encoding ismade at a different bit-rate. Further, in one embodiment, the AV files203 may include separate audio and video streams for one or more titles.In such a case, when a user requests a particular title, the audio andvideo streams delivered to a user may be multiplexed together byplayback logic on the BD-player 202 prior to being decoded and playedback to the user.

As shown, media delivery system 210 also includes media server 201coupled to the media library 212. Media server 201 generally isconfigured to retrieve a selected or specified file or files thatcomprise AV files 203 from the media library 212 in response to arequest from BD-Player 202 and deliver the files using a streaming mediaprotocol to the BD-Player 202 in response to the request. In oneembodiment, media server 201 is configured to deliver files stored inmedia library 212 using the HyperText Transfer Protocol (HTTP) and/orHTTP over Secure Socket Layer (HTTPS) through data network 226 toBD-Player 202. However, embodiments are not limited to any particularnetwork protocol and any suitable network protocol may be used todeliver AV program content from media delivery system 210 to BD-Player.

Also as shown, media selection service 214 includes a presentationserver 216, one or more application servers 218, and a database server220. The media selection service 214 may be integrated into orco-located with the media delivery system 210 as a single system, andthe media delivery system 210 may be implemented as an application onthe application servers 218 or otherwise contained within the mediaselection service 214. In the media selection service 214, the one ormore application servers 218 are coupled to the presentation server 216and database server 220.

The database server 220 maintains a user account 222 for a user of theservice including a media queue 224. The user account 222 is associatedwith a user at the ordering location 234 and the viewing location 228.The database server 220 is configured with an inventory of audiovisualprograms that are available for delivery using the media delivery system210. Application servers 218 and database server 220 is coupled throughnetwork 226 to media server 201 and other elements of media deliverysystem 210 (not shown), to enable the media delivery system 210 todetermine which AV files 203 are in media queue 224 for delivery to theviewing location 228. The presentation server 216 is configured withprograms for generating a user interface display, receiving user inputselecting audiovisual programs for rental or viewing, and otherfunctions.

The media queue 224 may provide a list of AV files 203 that a particularuser or user account has rented or requested to download or view. Thequeue 224 may include a list of both tangible media for rental, such asDVD titles, and AV files 203 for instant watching (i.e., streaming) orfor downloading. Media queue 224 also may represent multiple associatedqueues, so that the service 214 may maintain one queue of tangible mediafor rental and a separate but associated queue of audiovisual programsfor instant watching or downloading. Further, one user account 222 maybe associated with multiple user profiles each having a separate queuein any of the foregoing queue arrangements. In one embodiment, the mediaselection service 214 is the Netflix® service commercially availablefrom Netflix, Inc., Los Gatos, Calif.

Illustratively, viewing location 228 includes the BD-Player 202, aninput device 230, and a display 232. For purposes of illustrating aclear example, FIG. 2 shows one viewing location 228, but in a practicalembodiment there may be at least many thousands of viewing locationsconcurrently served by one or more media delivery systems 210.

BD-Player 202 includes any digital media player that complies with oneor more of the video based player profiles specified in the Blu-Ray®specification. At present the Blu-ray specification includes three videobased player profiles known as “Profile 1.0”, “Profile 1.1”, and“Profile 2.0” (“Profile 2.0” is referred to commercially as “BD-Live”).However, embodiments are not limited to digital media players thatimplement existing versions of the Blu-ray specification and includedigital media players that implement any future version of the Blu-rayspecification—or the protocols for streaming media to a networked clientdevice. In addition, BD-Player 202 may implement some or all portions ofthe Advanced Access Content System (AACS) standard for secure contentdistribution and digital rights management.

In one embodiment, BD-Player 202 is a computer system configured as aset-top box coupled to data network 226 and configured to receive AVfiles 203 and generate corresponding video output for a display 232 atviewing location 228. In such a case, the BD-player 202 may includefirmware with playback logic configured to multiplex audio and videofiles streamed by the media delivery system 210. Alternately, theplayback logic itself may be streamed to the BD-player 202. For example,the BD-player 202 may be configured to be capable of executing BD-J(Blu-ray Java®) applications retrieved over the Internet. In such acase, the BD-player 202 first downloads the playback logic as a BD-Japplication and then executes this application both to configure theBD-player 202 to play a title from media library 212 as well as toretrieve and multiplex audio video streams for the selected title.Non-limiting examples of set-top boxes include Blu-ray Disc playerdevices, streaming video playback boxes such as the Netflix Player byRoku, digital satellite television set-top boxes, video game consoles,digital video recorder (DVR) devices, cable converter boxes, or aset-top box device configured to support one or more video playerprofiles of the Blu-Ray® specifications. In another embodiment,BD-Player 202 is a desktop or workstation computer system configuredcoupled to data network 226 and configured with a digital media playerapplication that implements one or more video player profiles of theBlu-Ray® specifications (or other streaming media protocols) and that isconfigured to receive AV files 203 and generate corresponding videooutput for a display 232 at the viewing location 228.

Input device 230 is any user input device suitable for controlling theoperation of BD-Player 202. In an embodiment, input device 230 is aremote control device that uses infrared light-emitting diode emissions,radio-frequency signals, or wired signals to communicate with player 202and input device 230 comprises one or more control buttons for operatingfunctions of the player 202. For example, input device comprises a playbutton, a fast forward button, a rewind button, and a selection button.In another embodiment, input device 230 is an alphanumeric keyboard andmouse combination of the kind commonly connected to a personal computeror workstation computer

Display 232 is any display device capable of displaying motion pictureor video images according NTSC, PAL, ATSC, or other standards forconventional video, HD video, or other format. In an embodiment, display232 comprises a television monitor or other similar suitable videodisplay.

Ordering location 234 may provide a computer 236 that can connect topresentation server 216 through data network 226. For purposes ofillustrating a clear example, FIG. 1 shows one ordering location 234,but in a practical embodiment there may be many thousands of orderinglocations concurrently served by one or more media selection services214. In an embodiment, computer 236 is configured with a browser orother interface program that can connect to a complementary web serveror other server program to interact with functions provided by mediaselection service 214. The ordering location 234 and the viewinglocation 228 may be the same location or different locations in variousembodiments. Further, the functionality of computer 236 may be includedin BD-Player 202. For example, BD-Player 202 may be configured with abrowser or other user interface program that can connect to a web serveror other server program to interact with functions provided by mediaselection service.

FIG. 3 further illustrates the media server and media delivery system210 of FIG. 2, according to one embodiment of the invention. As shown,media delivery system 210 comprises a computing system having, withoutlimitation, a central processing unit (CPU) 305, a network interface315, an interconnect 320, a memory 325, and storage 330. The mediadelivery system 210 may also include an I/O devices interface 310connecting I/O devices 212 (e.g., keyboard, display and mouse devices)to the media delivery system 210.

The CPU 305 retrieves and executes programming instructions stored inthe memory 325. Similarly, the CPU 305 stores and retrieves applicationdata residing in the memory 325. The interconnect 320 facilitatestransmission of programming instructions and application data betweenthe CPU 305, I/O devices interface 310, storage 330, network interface315, and memory 325. CPU 305 is included to be representative of asingle CPU, multiple CPUs, a single CPU having multiple processingcores, and the like. And the memory 325 is generally included to berepresentative of a random access memory. The storage 330 may be a diskdrive storage device. Although shown as a single unit, the storage 330may be a combination of fixed and/or removable storage devices, such asfixed disc drives, floppy disc drives, tape drives, removable memorycards, optical storage, network attached storage (NAS), or a storagearea-network (SAN).

As shown, storage 330 includes elementary video and audio streams 350,352 and encoded video and audio streams 354, 356. And the memory 325includes an HTTP server 335 and an encoding tool 340. Each encoded audioand video file 354, 356 is included to represent a copy of the samegeneral media file, encoded at a different bit rate. Of course, inpractice, many distinct media titles may be available for streaming. TheHTTP server 335 may be configured to stream encoded video files 354 andencoded audio files 356 to a client device (e.g., BD-player 202) using astreaming media protocol. For example, in one embodiment, the encodedvideo files 354 and encoded audio files 356 are MPEG-2 complianttransport stream files encoding video (or audio) at a specified bitrate. In such a case, the HTTP server 335 may encapsulate MPEG-2 packetsin an HTTP stream and transmit them to a client device. More simply, themedia server 201 may stream one of the encoded video audio and files354, 356 selected from the encodings available in storage 330. In turn,the client device may multiplex the files and present them to a playbackengine (e.g., a BD-J application executing on a Blu-Ray® disc player)for decoding and playback.

In one embodiment, an encoding tool 340 may be configured to generatethe encoded video and audio files 354, 356 from an elementaryaudio/video stream files 350, 352, such as a high-definition H.264/AVCencoded file and a raw audio stream. By sampling the elementary AVstream files 350, 352 the encoding tool 340 may generate multiple video(and audio) encodings of the same media property, each encoded atdifferent bit rates. Further, the encoding tool 340 may generate theencoded video files 354 and/or encoded audio files 356 in a way so as toallow a client device (e.g., a Blu-ray disk player) to receive andmultiplex encoded video and audio data in order to generate amultiplexed stream presented to a playback engine on the client device.Further, the encoded video and audio files 354, 356 may be configured toallow the client device to vary the bit rate of the streaming mediacontent, i.e., to dynamically change which of the encoded video files354 (or audio files 356) is streamed to the client device.

In one embodiment, e.g., the particular encoded video and audio files354, 356 used to stream data may be determined by the client device as afunction of the prevailing bandwidth conditions. For example, the clientmay be configured to begin streaming playback by initially requestingthe lowest bit rate of encoded video files 354 and to increase thebit-rate up to the greatest rate supportable by the prevailing bandwidthbetween the client device and the media delivery system 210. Further, asthe available bandwidth changes, the bit rate at which the encoded videoand audio files 354, 356 is streamed may be changed. In such a case, theHTTP server 335 may change from streaming one encoding to the client toanother, in response to client requests for video (or audio) data fromdifferent encodings. However, rather than reconfiguring the clientdevice each time the streaming bit-rate is changed, the client devicemay pad portions of the encoded video file 354 such that the size of agiven portion matches the configured size of that portion specified tothe client device prior to streaming.

For example, each encoded video file 354 may provide a sequence ofgroups of pictures (GOPs), and a set of sequential GOPs may themselvesbe grouped, e.g., in groups of video 2 seconds in length. That is, eachencoded video file 354 may be subdivided into a number of clip files,and each clip file may include a sequential set of one or more GOPs froma given encoding. The clip files present in a given encoded video file354 may be specified in the header associated with that file. Further,the header may specify a number of insertion points (by byte or packetoffset) in each GOP for multiplexing audio data. In one embodiment,e.g., each GOP may correspond to two seconds of video playback and theheader may specify two insertion points for multiplexing audio data withthe video data. Corresponding GOPs in different encodings 354 representthe same sequence of pictures (i.e., represent the same two seconds ofvideo) and have the same insertion points. However, as the encoded videofiles 354 are generated at different bit rates, both the size and thebyte/packet offset for each GOP and each insertion point recorded willvary among different encodings. In one embodiment, the encoding tool 340may be configured to pad an encoded video file 354 with video fillerpackets such that each GOP begins with an I-frame and that each GOPbegins with an MPEG-2 packet having a continuity counter value of 0.Doing so allows a client device to switch from multiplexing one encodedvideo file 354 with an audio file 356 to a different encoded video file356, without reconfiguring the playback engine receiving the multiplexeddata or otherwise disrupting streaming media playback (save for a changein audio/video quality resulting from the changed bit-rate).

As noted, encoded video file 354 may include a file header indicatingthe packet (and/or byte) offset of each GOP (and insertion point formultiplexing) in that encoded video file 354. From this information, thesize of each GOP may be determined. As the clip files storing the GOPsare downloaded, the client device may compare the size of each GOP to areference size determined prior to initiating streaming playback.Further, the client device may pad each GOP as necessary so that thesize of each GOP in the multiplexed stream presented to the playbackengine is the same as specified in the client information file used toconfigure the playback engine.

Note, while each encoded video and audio files 354, 356 may generally bereferred to as having a bit rate using a fixed value (e.g., a bit rateof 1500 k per second) the actual bit rate may vary at different pointswithin a given encoding. As is known, variable bit rate (VBR) encodingtechniques adjust the bit rate of an encoding depending on the contentbeing encoded. For example, if there is little change in a visual scene,the bit rate at which content is encoded may be decreased. Conversely,if there is rapid change in the scene, the bit rate may increase, up tothe maximum specified for the encoding. Thus, VBR encoding offers ahigher audio-visual quality at a smaller file size.

FIG. 4 further illustrates BD-Player 202 of FIG. 2 in greater detail,according to one embodiment of the invention. As shown, BD-Player 202includes a network interface 438, local storage or memory 406, aremovable media device 440, playback logic 404, CPU 442, user inputprocessing unit 444, decoder 446, display device 432, and audio device348.

Playback logic 404 provides one or more sequences of computer executableinstructions for performing various functions that are described furtherherein. The instructions comprising playback logic 404 may be stored ona non-volatile memory of BD-player 202 such as, for example, a harddisk, flash memory, or firmware of BD player 202. Alternatively,instructions comprising playback logic 404 may be read by player 202from a removable non-volatile computer-readable storage medium (e.g., aBlu-ray Disc) using removable media device 440. Still further,instructions comprising playback logic 404 may be received over datanetwork 426 via network interface 438 (e.g., as a BD-J application).

The combination of network interface 438 and data network 426 broadlyrepresent any of the following: an Ethernet port configured to coupleBD-player 202 to a router, hub, DSL modem or adapter, or cable modem; anintegrated DSL modem or adapter, or cable modem; an Ethernet portconfigured to couple BD-player 202 to a wireless access point; and anyother electronic interface to a source of audiovisual program data, andthe like.

As noted, in one embodiment, playback logic 404 may comprise anexecutable Blu-Ray® Disc Java (BD-J) application read from a Blu-rayDisc inserted into player 402 and/or downloaded over network 426 frommedia server 201. In another embodiment, logic 404 is stored in firmwareof player 402, for example, in a flash ROM of player 402. In anotherembodiment, a bootstrap portion of logic 404 is stored in firmware ofplayer 402 and the bootstrap portion, when executed by CPU 342,downloads an application portion of logic 404 (e.g., an BD-J Xlet) frommedia server 201. The application portion of logic 404, when executed byCPU 442, performs the various functions that are described furtherherein. CPU 442 may comprise one or more processors and/or one or moreprocessor cores.

Local storage or memory 406 is a hard disk or flash memory for storingfiles; including playlist information files, clip information files, andAV stream files downloaded from media server 201 by playback logic 404.In one embodiment, playback logic 404 may configure decoder 446 toprocess a transport stream of a specified size and bit rate by causingplayer 202 to store a playlist information file and a metadatadescribing the collection of clip information files associated with agiven encoding of a media title. Thereafter, logic 404 may initiateplayback of the playlist by invoking a playback function provided by anapplication programming interface (API) offered by a system layer ofplayer 202. For example, once a user selects a media title for playback,the playback logic 404 may retrieve the headers associated with eachbit-rate encoding of that file and generate clip information filesdescribing the size and length of each clip (i.e., the sequence of GOPs)to be streamed as part of playing back the media file. Once thisinformation is received, the playback logic 404 may configure thedecoder to playback the selected media title and begin downloading theclips of the selected title at a particular bit rate. That is, theplayback logic 404 may be begin downloading the sequential audio andvideo clip files, multiplex them, and once the first clip file is fullydownloaded and multiplexed, send it to the decoder 446 for decoding andplayback on the display device 432 and audio device 448. If thedownloaded clips are smaller than the size specified when configuringthe decoder 446, the playback logic may pad each clip as appropriate.This process repeats as subsequent clips are downloaded.

In one embodiment, the playback logic 404 may switch the bit rate of thevideo (or audio) being downloaded. In such a case, the playback logicmay begin requesting clip files from a different encoding of the mediatitle than the one then currently being downloaded. Further, as eachencoding was constructed to include the same sequence of GOPs, and suchthat each GOP begins with an I-frame in an MPEG-2 packet having acontinuity counter of 0, the playback engine 404 may seamlessly switchfrom one bit rate encoding to another at any GOP boundary. That is, tochange the bit rate of streaming media playback, the playback enginesimply stops multiplexing GOPs from one encoding and begins multiplexingGOPs from another. As noted, to ensure the continuity count remainscorrect, GOPs may be padded with video filler packets so as to end witha continuity count of 15 (or the largest continuity count value).Decoder 446 refers broadly to a collection of hardware and/or softwarecomponents within BD-player 402 that takes as input a transport streamcontained in one or more AV stream files stored in local storage 406 andproduces as output decompressed video images and audio data for displaydevice 432 and audio device 448. Audio and video streams may be dividedinto packets (e.g., MPEG-2 packets) and encapsulated in one or morepackets of a transport stream. By interleaving/multiplexing transportstream packets containing video data and audio data, audio and videoelementary streams encoded at varying bit rates may be synchronized. Forexample, a transport stream may synchronize video encoded in anelementary stream at 2 Mbps with audio encoded in an elementary streamat 640 kbps. In one embodiment, the transport stream contained in an AVstream file stored in local storage 406 is a Moving Picture ExpertsGroup-2 (MPEG-2) Transport Stream (ISO/IEe 13818-1) contained in astructure compliant with the Blu-ray specification referred to in theBlu-ray specification as a “BDAV MPEG-2 Transport Stream”.

Decoder 446 may include any combination of sub-components such as abuffer for queuing transport stream packets read from an AV stream file,a de-multiplexer for de-multiplexing the stream of transport streampackets into separate elementary audio and video streams, and an audiodecoder and a video decoder for decompressing elementary audio and videostreams respectively.

User input processing unit 444 processes input signals received frominput device 430. An input signal processed by user input processingunit 444 may result in an event notification to a program or processexecuting instructions included in playback logic 404. Logic 404 may beconfigured to handle various types of event notifications from userinput processing unit 444. For example, playback logic 404 may receivean event notification when a user uses input device 430 to initiateplayback of an AV program or perform a seek function within an AVprogram. In response to receiving such an event notification, playbacklogic 404 may configure decoder 446 of player 202 to process the AVprogram at a particular bit rate by downloading and storing in localstorage 406 the playlist information file and clip information files ofthe AV program.

FIG. 5 illustrates a method 500 for encoding a media file to allow foron-device multiplexing on a networked client device, according to oneembodiment of the invention. As shown, the method 500 begins at step 505where an encoding tool generates multiple encoded video files for agiven media title (e.g., for a particular movie). For example, anencoding tool may sample a high-quality encoding (e.g., an H.264/AVCfile) or sample raw audio/video data to create multiple encoded files,each with a specified bit rate.

As part of the encoding process, each video stream may be constructed toallow a client device to dynamically switch between different bit ratesduring streaming media playback. At step 515, the encoding toolidentifies the position (by byte or packet offset) of insertion pointsin each GOP for audio multiplexing. For example, each GOP may representtwo seconds of video playback and insertion points may be selected tosubdivide each GOP into three relatively equal size chunks. Doing sosubsequently results in a multiplexed stream alternating betweentwo-thirds of second of video and audio data when the encoded audio andvideo files are streamed and multiplexed by the client device. At step520, the encoding tool may pad the end of each GOP with video fillerpackets as appropriate such that each GOP ends with a packet having acontinuity counter value of 15 (in the case of an MPEG-2 transportstream encoding). Doing so results in each GOP beginning with continuitycounter value of 0. Thus, as the client device only switches video bitrates on a GOP boundary, the continuity counter remains correct whendynamically switching bit rates during streaming media playback.

In one embodiment, at step 525, the packets in an encoded video file maybe aligned along a 6 Kb boundary (6128 bytes). Doing so allows for thevideo content to be encrypted using the AACS standard. As is known, withAACS, each aligned unit is independently encrypted using a CPS Unit Key.Note, rather than simply pad a portion of each GOP, one portion of a GOPmay “borrow” data from a subsequent portion, to minimize the amount ofpadding that is needed to create a 6128 byte AACS block. Additionally,the end of each GOP may be padded include video filler packets to allowthe last packet of the GOP to have a particular continuity counter value(e.g., 15). The resulting structure of each GOP and corresponding audiodata is further illustrated in FIG. 8, discussed below. At step 530, theencoding tool may generate a file header describing the content of anencoded stream. The file header may include, among other things, a fieldindicating the size of the header itself and a byte offset where videodata begins in the file. Further, the header may also include an indexindicating a position (by byte or packet) for the beginning of each GOPand the position of each audio insertion point (to allow for on-devicemultiplexing). The index may also specify the size of each GOP (to allowfor on-device padding). Steps 515-530 are performed to prepare eachencoded video file for streaming. Once completed, the resulting videoencodings may be stored on a media delivery system to be streamed toclients upon request.

At step 535, the encoding tool identifies the position (by byte orpacket offset) for splitting each audio segment into chunks formultiplexing. As described above, each audio chunk may correspond toapproximately two seconds of audio in the media file, and the insertionpoints may subdivide each chunk into approximately two-thirds of asecond of audio. Again, this results in a multiplexed stream alternatingbetween two-thirds of second of video and audio data when the encodedaudio and video files are streamed and multiplexed by the client device.At step 540, an index is generated for the audio file being processed.The index may indicate, among other things, a byte or packet offset foreach chunk of audio and each insertion point for multiplexing audio datawith video data. At step 545, like the encoded video files, each portionof an audio file resulting from the identified insertion points may bemay be padded so as to align along an encryption block boundary (e.g.,6128 bytes, allowing the audio content to be encrypted using the AACSstandard). Note, rather than simply pad each portion of audio data withnull packets, one portion of audio data may “borrow” packets from thesubsequent portion to minimize the amount of padding included in a 6128byte AACS block.

At step 550, the encoding tool may generate a file header describing thecontents of the audio file. The header may include, among others, afield indicating the size of the header itself and a byte (or packet)offset where the audio data begins, and also include the index indictingthe positions of the audio chunks and insertion points for multiplexingthe audio encoding with the video encodings. At step 555, the encodedaudio and video stream files may be stored on a media delivery system tobe streamed to clients upon request.

FIG. 6 illustrates a method 600 for on-device multiplexing of streamingmedia content delivered to a networked client device, according to oneembodiment of the invention. As shown, the method 600 begins at step 605where a client device requests the file header for each available videoand audio encoding of a selected media title (e.g., a particular movie).In one embodiment, the request may be two-fold, with a first request toidentify the size of a given header and a second request to retrieve thecomplete header based on the identified size. Once retrieved, at step610, the client device may store indices stored in the file headers. Asnoted above, the file header for each video may include an indication ofthe byte or packet offset of each video segment (i.e., each GOP) and theinsertion points for multiplexing the audio corresponding to each videosegment. Additionally, the index may indicate (or the client device mayderive) a size for each chunk of video (or each GOP) in a given encodedvideo file. Similarly, the header of an encoded audio file may includean indication of the positions of points at which to multiplex the audiochunks with the video.

At step 615, the client device may configure a playback engine toreceive a multiplexed transport stream. For example, in the case of aBlu-Ray® disc player, playback logic may configure a playback engine toreceive a BDAV MPEG-2 Transport Stream—which the client device willsubsequently generate by multiplexing video and audio stream datareceived from the streaming media server. The profile for such a BDAVMPEG-2 Transport stream may have a profile derived from the informationstored in the file headers requested at step 605 and indices stored atstep 610. Specifically, the size of each clip file to download from theserver may be derived from the collection of encoded video files. Aseach encoded video file stores the same sequence of GOPs (which maydiffer by packet number and byte size) the client device may configurethe playback engine to receive the largest clip file stored in any ofthe encoded video files. The largest clip file is selected so that anyclip file actually used may be padded if needed to match the size of thelargest clip file. That is, as noted above, in the event that a clipfile is streamed from one of the video encodings with a size less thenthe largest one, such a file may be padded so as to match the size usedto configure the playback engine on the client device.

In the event that multiple audio files are available, then the sizes ofthe audio segments in the available audio encodings may be used toconfigure the playback engine in a similar manner. Otherwise, if thefile is to be streamed and multiplexed by the client device using asingle audio encoding and possibly multiple video bit-rate encodings,then the size of the audio segments indicated in the header of theselected audio encoding is used to configure the playback engine.

Once configured, at step 620, the client device may begin downloadingthe next (or initial) segments of audio and video streams and store thestreamed data in a buffer as it is received from the streaming mediaserver. At step 625, once a segment of video data is available (e.g., acomplete GOP) and a corresponding segment of audio data is available,the client device may multiplex the audio and video streams receivedfrom the server based on the insertion points indicated in the indicesstored at step 610. Additionally, if any GOP in the video stream is lessthan the configured size, such a GOP may be padded to match the sizeused to configure the playback engine on the client device. At step 630,the multiplexed segments of audio and video may be passed to theplayback engine on the client device for decoding and playback to auser.

At step 635, unless the bit rate for streaming video (or optionallyaudio) data has changed, then the method 600 returns to step 620 andwhere the client device begins downloading the next segments of audioand video data for multiplexing. Otherwise, if the bit rate has changed,the client device may identify the end of a current GOP downloaded fromthe server at a current bit rate (step 640). At step 650, the clientdevice identifies the video file which stores the next GOP encoded atthe new bit rate. Thereafter, the method 600 returns to step 620 wherethe client device begins downloading audio data and downloading videodata at the new bit rate. Data from the encoded video file having thenew bit rate may then be multiplexed with the audio data along a GOPboundary and supplied to the playback engine for decoding and playbackto the user.

While the client device (or the streaming media server) may elect tochange the bit rate of video data streamed to the client for a varietyof reasons, in one embodiment, the bit rate may be changed in responseto changes in prevailing bandwidth conditions and the amount ofstreaming media then buffered on the client device. As another example,bit rates may be changed shortly after initiating playback, e.g., theclient may first request video data at the lowest available encoded bitrate, allowing for a rapid start up of video playback. Subsequently, theclient may then increase the bit rate as the prevailing bandwidthconditions allow to improve the video quality of video decoded andpresented to a user.

FIG. 7 illustrates an example of multiplexing a video stream with anaudio stream supplied to a playback engine, according to one embodimentof the invention. As shown, a first video stream 705 and a second videostream 710 each include sequential GOPs encoding a portion of a mediatitle (labeled GOP1 through GOP4). And an audio stream 715 includes asequence of audio clips corresponding to the GOPs in video streams 705and 710 (labeled Audio Clip 1-Audio Clip 4). Illustratively, each GOP invideo stream 705 and 710 and audio stream 715 includes hash marks (e.g.,marks 750 and 755 in GOP1 and marks 770 and 775 in audio stream 715)indicating the positions stored in the file header associated with arespective video stream 705, 710 and audio stream 715 for multiplexingthe audio and video data in these streams.

Additionally, FIG. 7 illustrates an example multiplexed stream 720 beingconstructed from the video streams 705, 710 and audio stream 715. Asshown, the multiplexed stream 720 alternates between portions of videoand audio data. For example, multiplexed stream 720 includes a firstchunk 725 of video data taken from GOP1 followed by a first chunk 730 ofaudio data taken from Audio Clip 1. This pattern then repeats as themultiplexed stream 720 then includes a second chunk 760 of video datafrom GOP1 followed by a second chunk 765 of audio data from Audio Clip1. Assume for this example, that the client device multiplexing videodata from video stream 705 and audio data from audio stream 715 electsto change the bit rate of the video data being streamed from 1500 kbps(stream 705) to 1000 kbps (stream 710). As described above, the encodedvideo streams available from a server may be encoded to allow for aswitch in bit rates along a GOP boundary.

Accordingly, following the second audio clip 765, the client devicemultiplexes the remaining portions of GOP1 and Audio Clip 1 intomultiplexed stream 720. The client device then downloads GOP2 from videostream 710 and multiplexes a first chunk 735 of GOP2 into themultiplexed stream 720 followed by a first chunk 745 of audio data takenfrom Audio Clip 2. Note, in this example, as the first chunk 735 of GOP2was retrieved from a lower-bit rate stream, it is smaller then the sizeof this portion of the video data specified to the playback engineduring the configuration process. Accordingly, prior to multiplexing thefirst chunk 745 of audio data from Audio Clip 2 into multiplexed stream720, the client device may add padding 740 as appropriate such that thesize of the first chunk 735 of video data from GOP2 matches theconfigured size of this portion of video data. The client devicecontinues multiplexing the streamed portions of audio and video data andsupplying the resulting multiplexed stream 720 to the playback enginefor decoding and playback to a user.

FIG. 8 further illustrates portions of audio and video data encoded inaudio and video streams prior to being multiplexed on a client device,according to one embodiment of the invention. As shown, FIG. 8 includesa GOP 805 and a portion 810 of an audio file storing approximately 2seconds of encoded audio. The GOP 805 generally corresponds to any ofthe GOPs in the video streams 705, 710 shown in FIG. 7. Similarly, audioportion 810 generally corresponds to any of the audio clips in audiostream 715 shown in FIG. 7.

In this example, GOP 805 includes three portions of video data. Eachvideo part 815 ₁₋₃ corresponds to one third of the GOP 805. Each videopart 815 ₁₋₃ may include a number of packets of video data (e.g., MPEG-2transport stream packets) and end at an insertion point for multiplexingwith audio portion 810, as identified during the encoding process. Forexample, video part 815 ₁ of GOP 805 may correspond to the first chunkof GOP 1 shown in FIG. 7. And video parts 815 ₂ and 815 ₃ of GOP 805 maycorrespond to the second and third chunks of GOP 1 shown in FIG. 7.Similarly, audio part 830 ₁ may generally correspond to the first chunkof audio stream 710 shown in FIG. 7.

Following each of the video parts 815 ₁₋₃ is DRM (digital rightsmanagement) padding 820 ₁₋₃. In one embodiment, DRM padding 820 is addedto each of the video parts 815 ₁₋₃ as needed in order to align a givenpart 805 along an encryption block boundary (e.g., a 6128 byte AACSblock boundary). For example, the DRM padding 820 may simply be nullpackets added as needed. Alternatively, however, the DRM padding 820 may“borrow” data packets from the next portion of video data. Thus, the DRMpadding 820 ₁ following video part 815 ₁ may include null packets, datapackets borrowed from video part 815 ₂, or both. Similarly, the DRMpadding 820 ₂ following video part 815 ₂ may include null packets, datapackets borrowed from part 815 ₃, or both. However, part 815 ₃ includescontinuity counter (CC) padding 825 prior to DRM padding 820 ₃. In thisexample, GOP 805 is padded with video filler packets as appropriate suchthat GOP 805 ends with a packet having a particular continuity countersuch that the first video data packet in the next GOP will have acontinuity counter value of 0. Following the CC padding 825 (if any) isDRM padding 820 ₃, which consists of null padding packets used to alignvideo part 815 ₃ along an encryption block boundary.

Audio portion 810 includes DRM padding similar to that of GOP 805. Thatis, following each audio part 830 ₁₋₃ is DRM padding 835 ₁₋₃.Specifically, DRM padding 835 ₁ following audio part 830 ₁ includes nullpackets, data packets borrowed from audio part 830 ₂, or both. And DRMpadding 835 ₂ following audio part 830 ₂ includes null packets, packetsborrowed from audio part 830 ₃, or both. Lastly, DRM padding 835 ₃following audio part 830 ₃ includes null padding packets. By paddingeach video part 815 ₁₋₃ of GOP 805 and each part 830 ₁₋₃ of audioportion 810, each of these segments of audio and video data fall alongan encryption block boundary. Further, by padding the end of each GOPwith CC padding 825, GOPs from different available video encoding mayfollow one another.

In sum, techniques are disclosed for multiplexing a dynamic bit-ratevideo stream with an audio stream received by a client device in amanner that allows the resulting multiplexed stream to be played backwithout disruption, despite dynamic changes in the bit rate of the videostream that may occur. Doing so allows, e.g., a BD-player to seamlesslychange bit rates during playback, i.e., to change bit rates withoutrequiring the BD-player to be reconfigured with changed size data orcausing a noticeable interruption of smooth audio and video playbackeach time the streaming bit rates are changed. As video data isdownloaded for playback, the size of the clip file (or the size of GOPsin the clip file) is compared with a corresponding clip informationfile. The clip information file may be used to configure the BD-Playerprior to initiating playback of streaming AV data. Playback logicexecuting on the BD-Player may pad the clip file (or one or more GOPs inthe clip file) such that the size of the clip file matches theconfigured size specified in the clip information file. Once padded asappropriate, the video data may be multiplexed with audio data andsupplied to a playback engine for decoding and presentation to a viewer.

One embodiment of the invention may be implemented as a program productstored on computer-readable storage media within the client device. Inthis embodiment, the content client device may be embedded within acomputing device such as a set top box or BD-player. An alternativeembodiment may be implemented as a program product that is downloaded toa memory within a computer system, for example as executableinstructions embedded within an Internet web site. In this embodiment,the client device comprises the computer system.

While the forgoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof. For example, aspects of thepresent invention may be implemented in hardware or software or in acombination of hardware and software. One embodiment of the inventionmay be implemented as a program product for use with a computer system.The program(s) of the program product define functions of theembodiments (including the methods described herein) and can becontained on a variety of computer-readable storage media. Illustrativecomputer-readable storage media include, but are not limited to: (i)non-writable storage media (e.g., read-only memory devices within acomputer such as CD-ROM disks readable by a CD-ROM drive, flash memory,ROM chips or any type of solid-state non-volatile semiconductor memory)on which information is permanently stored; and (ii) writable storagemedia (e.g., floppy disks within a diskette drive or hard-disk drive orany type of solid-state random-access semiconductor memory) on whichalterable information is stored. Such computer-readable storage media,when carrying computer-readable instructions that direct the functionsof the present invention, are embodiments of the present invention.

In view of the foregoing, the scope of the present invention isdetermined by the claims that follow.

We claim:
 1. A computer-implemented method, comprising: receiving a fileheader associated with a media file, wherein the media file includes oneor more insertion points where a sub-portion of video data ismultiplexed with a sub-portion of audio data, and a first file header inthe plurality of file headers includes an indication of a position ofeach of the one or more insertion points within a first video encodingassociated with the media file; downloading a first portion of the firstvideo encoding and a second portion of an audio encoding associated withthe media file; generating a first segment of a multiplexed stream bymultiplexing the first portion of the first video encoding with thesecond portion of the audio encoding based on the indications of thepositions of the insertions points included in the first file header;and transmitting the first segment for playback.